3PCC (the Third Party of Conversation Control) means that the third party controller creates a session between other two parties, and the controller is responsible for the media negotiation between the two parties of the session. 3PCC is a very flexible controlling mode, which may be divided into the flow where a 3PCC creation request message carries a SDP (Session Description Protocol) message and the flow where the 3PCC creation request message does not carry the SDP message, wherein, the SDP message comprises an Offer message and an Answer message.
The flow where the 3PCC creation request message carries the SDP message exists in call forwarding, automatic machine and call transferring and other services, which is specifically as shown in FIG. 1 and comprises the following steps.
Step 101, the first party has made a media negotiation with an AS (Application Server).
Step 102, the AS sends an Offer message to the second party.
Wherein, the Offer message may be born in a call creation request message, which may be but not limited to an Invite message.
Step 103, the second party sends an Answer message to the AS after receiving the Offer message.
Wherein, the Answer message may be born in a reliable transmission temporary response message, which comprises but is not limited to a 180 response message, a 181 response message or a 183 response message.
Wherein, the Answer message comprises descriptions on media type, a confirmation request for the Precondition state of the first party, transmission protocol, media format and so on. Wherein, the Precondition state may be but not limited to QoS (Quality of Service) state, and the Precondition state requires a level of mandatory.
Step 104, the AS receives the Answer message and sends the Offer message to the first party.
Wherein, the Offer message may be born in an update request message, which comprises but is not limited to an Update message and a Re-invite message.
Specifically, the AS extracts the Answer message after receiving the reliable transmission temporary response message carrying the Answer message, transforms the extracted Answer message into the Offer message, and sends the Offer message to the first party by bearing the Offer message in an update request message.
Step 105, the first party sends the Answer message to the AS after receiving the Offer message.
Wherein, the Answer message may be born in an update request response message, wherein, the update request response message comprises but is not limited to a 200 OK response message or a 183 response message. Wherein, the Answer message comprises descriptions on media type, a confirmation response of the Precondition state from the first party, transmission protocol and media format and so on. Wherein, the Precondition state may be but not limited to QoS (Quality of Service) state, and the Precondition state requires a level of mandatory.
In the implementation of the invention, the following questions are found by the inventor in the existing technologies:
Since the second party needs the confirmation response to the Precondition state from the first party, the first party sends the confirmation response to the Precondition state to the AS by bearing it in the Answer message in step 105, but the AS will intercept the Answer message, thus causing the call to be unable to proceed.